✅ Deploy Preview for rp-cloud ready!

Name	Link
🔨 Latest commit	96b9bfe
🔍 Latest deploy log	https://app.netlify.com/projects/rp-cloud/deploys/6a6917c492ad6600085db255
😎 Deploy Preview	https://deploy-preview-643--rp-cloud.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

sequenceDiagram
  participant Azure BYOC cluster
  participant Azure spoke VNet
  participant Azure hub VNet
  participant Azure Firewall
  participant Internet
  Azure BYOC cluster->>Azure spoke VNet: Send internet-bound traffic
  Azure spoke VNet->>Azure hub VNet: Forward traffic through peering
  Azure hub VNet->>Azure Firewall: Route traffic to firewall private IP
  Azure Firewall->>Internet: SNAT traffic through static public IP
  Internet->>Azure Firewall: Return traffic
  Azure Firewall->>Azure spoke VNet: Forward return traffic

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

@ppanagiotis I think we should also provide Terraform based docs as well, do you know how the TF provider is progressing?

@ppanagiotis I think we should also provide Terraform based docs as well, do you know how the TF provider is progressing?

I will work on update the Terraform providers next week. And I will update docs also.

PR Review (docs-team-standards)

Critical issues (must fix)

1. nat-free-egress.adoc (Use the Cloud API): the standalone API example uses a different, likely invalid JSON shape than every other example. Every other /v1/networks example in controlplane-api.adoc — including the Azure one this PR adds to the partial — wraps the payload in "network": { ... } and includes "resource_group_id". The standalone example in nat-free-egress.adoc omits both. If the enveloped form is correct (it's the canonical one used repo-wide), this copy-paste example would fail, and the two examples of the same call disagree.

   • Fix: Make the nat-free-egress.adoc example match the partial: wrap in "network": {} and add "resource_group_id". Confirm the correct shape against the API before changing.

2. Contradictory dependency order for VNet peering. nat-free-egress.adoc Prerequisites lists "You have created the VNet peering from the hub to the Redpanda spoke VNet" as done before configuring egress. But azure-hub-egress.adoc states the spoke VNet resource ID is only "visible in the Redpanda Cloud console after the network is created," and that the hub-side peering "stays in a non-connected state until Redpanda creates the reciprocal peering during cluster provisioning." Readers can't create the hub→spoke peering before the network exists (no spoke ID yet), yet the prerequisite says they must.

   • Fix: Clarify the actual sequence (hub + firewall first → create network to get spoke VNet ID → create hub-side peering → cluster provisioning completes the reciprocal peering) and align the prerequisite wording with the hub page.

Suggestions (should consider)

1. azure-hub-egress.adoc (Create the Azure Firewall): "approximately $1.25 per hour" will go stale. Consider linking to Azure Firewall pricing instead of stating a figure.
2. Beta glossterm: The What's New entry uses glossterm:beta[], but the new pages use plain "beta" in prose (they do set :page-beta: true for the badge). Optional: use glossterm:beta[] on first mention in prose for consistency.
3. create-byoc-cluster-azure.adoc (TIP): Minor repetition — "...is only enabled if centralized egress is enabled for your organization." Consider "...only if centralized egress is enabled for your organization."
4. nat-free-egress.adoc Prerequisites: 10.255.0.0/16 is described as a "safe default." It's already hedged with an overlap WARNING, so this is minor, but "example range you should verify against your networks" is safer phrasing.

PR Review, round 2 (docs-team-standards)

Thanks for the quick turnaround — the latest push addresses everything from my last review and all of the CodeRabbit comments. I verified the API surface this time (request envelopes, required fields, the PATCH field-mask shape, the two-apply toggle behavior and the agent warning, the spoke-side peering flags, and the 0.0.0.0/0 UDR), and it all checks out. Four things left.

Critical issues (must fix)

1. nat-free-egress.adoc lines 119 and 182: the Cloud UI does support changing egress on an existing network. Both spots say it doesn't ("Changing centralized egress on an existing network is not yet available in the Cloud UI; use the Cloud API instead"). But on the network details page there's a Hub VNet setting row with Add/Edit (and a remove option) that updates egress_spec on the existing network and then prompts you to run rpk cloud byoc azure apply. It's behind the same per-organization gate as the create-time fields.

   • Fix: Replace both statements, and document the network details procedure (Networks → select the network → Hub VNet → Add/Edit → re-run rpk cloud byoc azure apply). The PR description says "API-only today (no Cloud UI support)" — worth updating that too.

2. nat-free-egress.adoc lines 119 and 253: broken cross-references in the published site. Both reference <<update-existing-network,Update egress on an existing network>> from outside the ifdef::show-preview-api[] block, but that anchor is inside it (lines 179–205). show-preview-api isn't set anywhere in this repo, so on the live site those render as broken references — and the update flow ends up documented nowhere, even though the UI supports it.

   • Fix: Falls out of item 1. Document the UI update path ungated, and keep only the curl variants inside the gate.

3. nat-free-egress.adoc lines 46 and 238: allow_gateway_transit fix applied only partway. The prose (line 93), the responsibility table (line 106), and the second troubleshooting row (line 241) now correctly say allow_forwarded_traffic is the flag that matters. Two spots still disagree with them:

   • Line 238 tells readers to verify "the hub-side peering has allow_gateway_transit enabled" when cluster creation fails → should be allow_forwarded_traffic.
   • Line 46, the diagram, labels the hub side allow_gateway_transit=true → should be allow_forwarded_traffic=true.

4. Two ungated pages point readers at the Cloud API path that the rest of the PR deliberately hides. The API sections are gated behind show-preview-api because the field is still preview, but:

   • whats-new-cloud.adoc line 22: "You can set this up in the Cloud UI or Cloud API when you create the network, or add or change it on an existing network through the Cloud API" — sends readers to a path no published page documents.
   • create-byoc-cluster-azure.adoc TIP: names egress_spec.azure.hub_vnet_id and firewall_private_ip plus the Cloud API. The AWS and GCP equivalents in that same file mention only the UI fields.
   • Fix: Describe only the UI path in both, which is the complete story once item 1 is in.

Suggestions (should consider)

1. UI field labels: they render as Hub egress VNet ID (optional) and Firewall private IP (optional), and the form requires the two to be supplied together. Worth noting the pairing requirement in the Cloud Console step, not just in the gated API section.
2. Worth adding: the hub-egress route table is created with BGP route propagation disabled, so the default route to the firewall can't be overridden. Since the page discusses hub VPN/ExpressRoute gateways, readers may expect BGP routes to reach the Redpanda subnets — they won't.
3. "creates one Azure NAT Gateway per availability zone" is a fixed count; the NAT Gateway count is configurable. "One or more NAT Gateways in the Redpanda VNet" avoids going stale.
4. Terminology: the heading === Use the Cloud Console and three uses of "Redpanda Cloud console" (lowercase) run against the repo baseline of "Redpanda Cloud Console" / "Redpanda Cloud UI"; the AWS and GCP siblings use prose ("use the Redpanda Cloud UI") with no heading. learning-objective-1 also says "Redpanda Cloud UI" while the heading says "Cloud Console."
5. azure-hub-egress.adoc, Plan for high availability: "New Azure Firewall deployments are zone-redundant by default in regions that support availability zones" is a strong platform claim with no citation — link the Microsoft availability-zones doc. (The paired claim that the Terraform module sets no explicit zones is accurate.)

What works well

• Faithful mirror of the AWS and GCP page pair, so all three providers now read consistently.
• The two-apply explanation for toggling egress on or off, including the deferred-deletion warning, is exactly right. That's the detail most likely to generate a support ticket and it's covered.
• Clear shared-responsibility table and a genuinely useful troubleshooting table.
• Terraform escape hatch linked to a module that exists.

Happy to push these edits to DOC-2384 myself if that's easier than hand-applying them — just say the word. Separately, I'll file a follow-up for the AWS and GCP POST /v1/networks examples, which have a request-shape bug this PR's Azure example doesn't; no need to touch them here.